เชี่ยวชาญการตรวจสอบความถูกต้องของฟอร์มด้วย `experimental_useFormStatus` ของ React

ฟอร์มคือรากฐานที่สำคัญของการโต้ตอบบนเว็บ ตั้งแต่การสมัครรับจดหมายข่าวอย่างง่ายไปจนถึงแอปพลิเคชันทางการเงินที่ซับซ้อนหลายขั้นตอน ฟอร์มเป็นช่องทางหลักที่ผู้ใช้ใช้สื่อสารกับแอปพลิเคชันของเรา แต่เป็นเวลาหลายปีที่การจัดการสถานะฟอร์มใน React เป็นบ่อเกิดของความซับซ้อน, โค้ดที่ต้องเขียนซ้ำซาก (boilerplate) และความเหนื่อยล้าจากการพึ่งพาไลบรารีต่างๆ เราต้องสลับไปมาระหว่าง controlled components, ต่อสู้กับไลบรารีจัดการสถานะ และเขียน `onChange` handlers นับไม่ถ้วน ทั้งหมดนี้ก็เพื่อสร้างประสบการณ์ผู้ใช้ที่ราบรื่นและใช้งานง่าย

ทีมงาน React ได้คิดทบทวนเกี่ยวกับแง่มุมพื้นฐานของการพัฒนาเว็บนี้อีกครั้ง ซึ่งนำไปสู่การแนะนำกระบวนทัศน์ใหม่ที่ทรงพลังซึ่งมีศูนย์กลางอยู่ที่ React Server Actions โมเดลใหม่นี้สร้างขึ้นบนหลักการของ progressive enhancement โดยมีเป้าหมายเพื่อลดความซับซ้อนในการจัดการฟอร์มโดยย้ายตรรกะไปไว้ใกล้กับที่ที่มันควรอยู่ ซึ่งบ่อยครั้งก็คือเซิร์ฟเวอร์ หัวใจของการปฏิวัติฝั่งไคลเอ็นต์นี้คือ hook ทดลองใหม่สองตัว ได้แก่ `useFormState` และดาวเด่นของการสนทนาของเราในวันนี้ `experimental_useFormStatus`

คู่มือฉบับสมบูรณ์นี้จะพาคุณไปเจาะลึก hook `experimental_useFormStatus` เราจะไม่เพียงแค่มองที่ไวยากรณ์ของมัน แต่เราจะสำรวจโมเดลความคิดที่มันเปิดใช้งาน: ตรรกะการตรวจสอบความถูกต้องตามสถานะ (Status-Based Validation Logic) คุณจะได้เรียนรู้ว่า hook นี้แยก UI ออกจากสถานะของฟอร์มได้อย่างไร, ทำให้การจัดการสถานะที่รอดำเนินการ (pending states) ง่ายขึ้น และทำงานร่วมกับ Server Actions เพื่อสร้างฟอร์มที่แข็งแกร่ง, เข้าถึงได้ และมีประสิทธิภาพสูงซึ่งทำงานได้แม้กระทั่งก่อนที่ JavaScript จะโหลดเสร็จ เตรียมพร้อมที่จะคิดใหม่ทุกสิ่งที่คุณเคยรู้เกี่ยวกับการสร้างฟอร์มใน React

การเปลี่ยนแปลงกระบวนทัศน์: วิวัฒนาการของฟอร์มใน React

เพื่อให้เข้าใจถึงนวัตกรรมที่ `useFormStatus` นำมาอย่างถ่องแท้ เราต้องเข้าใจเส้นทางการจัดการฟอร์มในระบบนิเวศของ React ก่อน บริบทนี้จะช่วยเน้นย้ำถึงปัญหาที่แนวทางใหม่นี้เข้ามาแก้ไขได้อย่างสง่างาม

ยุคเก่า: Controlled Components และไลบรารีภายนอก

เป็นเวลาหลายปีที่แนวทางมาตรฐานสำหรับฟอร์มใน React คือรูปแบบ controlled component ซึ่งเกี่ยวข้องกับ:

• การใช้ตัวแปร state ของ React (เช่น จาก `useState`) เพื่อเก็บค่าของแต่ละ input ในฟอร์ม
• การเขียน `onChange` handler เพื่ออัปเดต state ทุกครั้งที่มีการกดแป้นพิมพ์
• การส่งค่าตัวแปร state กลับไปยัง prop `value` ของ input

แม้ว่าวิธีนี้จะทำให้ React ควบคุมสถานะของฟอร์มได้อย่างสมบูรณ์ แต่มันก็นำมาซึ่ง boilerplate จำนวนมาก สำหรับฟอร์มที่มีสิบฟิลด์ คุณอาจต้องใช้ตัวแปร state สิบตัวและฟังก์ชัน handler สิบฟังก์ชัน การจัดการการตรวจสอบความถูกต้อง, สถานะข้อผิดพลาด และสถานะการส่งข้อมูลยิ่งเพิ่มความซับซ้อนมากขึ้นไปอีก ซึ่งมักจะทำให้นักพัฒนาต้องสร้าง custom hooks ที่ซับซ้อนหรือหันไปใช้ไลบรารีภายนอกที่ครอบคลุม

ไลบรารีอย่าง Formik และ React Hook Form ได้รับความนิยมอย่างสูงจากการที่มันช่วยลดความซับซ้อนเหล่านี้ พวกมันมอบโซลูชันที่ยอดเยี่ยมสำหรับการจัดการสถานะ, การตรวจสอบความถูกต้อง และการปรับปรุงประสิทธิภาพ อย่างไรก็ตาม พวกมันก็เป็นอีกหนึ่ง dependency ที่ต้องจัดการ และมักจะทำงานทั้งหมดบนฝั่งไคลเอ็นต์ ซึ่งอาจนำไปสู่ตรรกะการตรวจสอบความถูกต้องที่ซ้ำซ้อนกันระหว่าง frontend และ backend

ยุคใหม่: Progressive Enhancement และ Server Actions

React Server Actions นำมาซึ่งการเปลี่ยนแปลงกระบวนทัศน์ แนวคิดหลักคือการสร้างบนรากฐานของแพลตฟอร์มเว็บ นั่นคือองค์ประกอบ HTML `

` มาตรฐาน ฟอร์มที่มี server action จะทำงานเหมือนกับการส่งฟอร์ม HTML แบบคลาสสิก—มันสามารถทำงานได้อย่างสมบูรณ์แบบแม้ว่า JavaScript จะล้มเหลวหรือถูกปิดใช้งาน นี่คือสาระสำคัญของ progressive enhancement

เมื่อ JavaScript โหลดเสร็จ React จะเข้าควบคุมกระบวนการส่งฟอร์ม ป้องกันการโหลดหน้าใหม่ทั้งหมดและดำเนินการ server action แบบอะซิงโครนัส สิ่งนี้ทำให้เราได้สิ่งที่ดีที่สุดจากทั้งสองโลก: ความทนทานของแอปพลิเคชันที่เรนเดอร์ฝั่งเซิร์ฟเวอร์ และประสบการณ์การโต้ตอบที่สมบูรณ์ของ single-page application (SPA)

โมเดลนี้ย้ายแหล่งที่มาของความจริง (source of truth) สำหรับตรรกะทางธุรกิจและการตรวจสอบความถูกต้องกลับไปที่เซิร์ฟเวอร์ (หรือสภาพแวดล้อมที่เหมือนเซิร์ฟเวอร์) โค้ดฝั่งไคลเอ็นต์จะง่ายขึ้น โดยส่วนใหญ่จะเกี่ยวข้องกับการเรนเดอร์ UI ตาม *สถานะ* ของการสื่อสารกับเซิร์ฟเวอร์นั้น และนี่คือจุดที่ `useFormStatus` เข้ามามีบทบาทสำคัญอย่างยิ่ง

เบื้องหลังการทำงาน: `experimental_useFormStatus` คืออะไร?

hook `experimental_useFormStatus` เป็นเครื่องมือฝั่งไคลเอ็นต์ที่ออกแบบมาเพื่อให้ข้อมูลเกี่ยวกับการส่งข้อมูลครั้งล่าสุดขององค์ประกอบ `` ที่เป็น parent ของมัน มันเป็น hook แบบอ่านอย่างเดียว (read-only) ที่บอกคอมโพเนนต์ทุกสิ่งที่จำเป็นต้องรู้เกี่ยวกับสถานะการส่งของฟอร์มโดยไม่จำเป็นต้องส่ง props ใดๆ ลงมา

ฟังก์ชันการทำงานหลัก

ลองนึกภาพปุ่ม submit ภายในฟอร์มขนาดใหญ่ ปุ่มนี้จะรู้ได้อย่างไรว่าฟอร์มกำลังอยู่ในระหว่างการส่งข้อมูล? ตามธรรมเนียมแล้ว คุณจะต้องส่งตัวแปร state อย่าง `isSubmitting` ผ่านคอมโพเนนต์หลายชั้น (prop drilling) แต่ด้วย `useFormStatus` คอมโพเนนต์ปุ่มสามารถค้นหาข้อมูลนี้ได้ด้วยตัวเอง

hook นี้จะต้องถูกเรียกจากคอมโพเนนต์ที่ถูกเรนเดอร์ *ภายใน* องค์ประกอบ `` จากนั้นมันจะให้ข้อมูลสถานะเกี่ยวกับวงจรชีวิตของฟอร์มนั้นๆ

ส่วนประกอบของ `useFormStatus` Hook

เมื่อคุณเรียกใช้ `const status = useFormStatus()` คุณจะได้รับอ็อบเจกต์กลับมาพร้อมกับคุณสมบัติหลักดังต่อไปนี้:

• `pending` (boolean): นี่เป็นคุณสมบัติที่ใช้บ่อยที่สุด มันจะเป็น `true` หากฟอร์ม parent กำลังถูกส่ง และเป็น `false` ในกรณีอื่น มันเหมาะอย่างยิ่งสำหรับการปิดใช้งานปุ่ม, แสดง loading spinners หรือจัดรูปแบบสถานะที่รอดำเนินการ
• `data` (FormData): อ็อบเจกต์ที่ใช้งาน `FormData` interface มันมีข้อมูลที่ถูกส่งไปพร้อมกับฟอร์ม สิ่งนี้มีประโยชน์อย่างเหลือเชื่อสำหรับการทำ optimistic UI updates—ตัวอย่างเช่น การแสดงความคิดเห็นของผู้ใช้ในรายการทันทีหลังจากที่พวกเขาส่ง แม้กระทั่งก่อนที่เซิร์ฟเวอร์จะยืนยันการสร้างก็ตาม
• `method` (string): เมธอด HTTP ('get' หรือ 'post') ที่ใช้สำหรับการส่งฟอร์ม
• `action` (function): การอ้างอิงถึงฟังก์ชัน server action ที่ถูกเรียกใช้ระหว่างการส่ง

กฎทอง: ต้องเป็นลูกของ ``

กฎสำคัญที่ต้องจำคือคอมโพเนนต์ที่ใช้ `useFormStatus` จะต้องถูกเรนเดอร์เป็นลูกขององค์ประกอบ `` ที่มันกำลังติดตามอยู่ มันไม่สามารถอยู่ในคอมโพเนนต์เดียวกับที่เรนเดอร์แท็ก `` ได้ เพราะมันต้องการเข้าถึง context ของฟอร์ม นี่คือเหตุผลที่คุณมักจะเห็นคอมโพเนนต์อย่าง `` ถูกสร้างขึ้นแยกต่างหากเพื่อเก็บตรรกะของ `useFormStatus`

ตัวอย่างง่ายๆ: ปุ่ม Submit อัจฉริยะ

มาดูกรณีการใช้งานที่พบบ่อยที่สุดกัน แทนที่จะใช้ `` แบบมาตรฐาน เราจะสร้างคอมโพเนนต์ที่รับรู้สถานะการส่งของฟอร์ม

ไฟล์: SubmitButton.js

import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton() { const { pending } = useFormStatus(); return (

{pending ? 'กำลังส่ง...' : 'สมัครสมาชิก'} ); }

ไฟล์: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // Server action export function SignUpForm() { return ( อีเมล:
); }

ในตัวอย่างนี้ `SubmitButton` เป็นคอมโพเนนต์ที่สมบูรณ์ในตัวเอง มันไม่ได้รับ props ใดๆ มันใช้ `useFormStatus` เพื่อรับรู้ว่า `SignUpForm` กำลังอยู่ในสถานะ pending และจะปิดการใช้งานตัวเองและเปลี่ยนข้อความโดยอัตโนมัติ นี่เป็นรูปแบบที่ทรงพลังสำหรับการแยกส่วน (decoupling) และสร้างคอมโพเนนต์ที่นำกลับมาใช้ใหม่ได้และรับรู้สถานะของฟอร์ม

หัวใจของเรื่อง: ตรรกะการตรวจสอบความถูกต้องตามสถานะ

ตอนนี้เรามาถึงแนวคิดหลัก `useFormStatus` ไม่ได้มีไว้สำหรับสถานะการโหลดเท่านั้น แต่มันเป็นตัวเปิดใช้งานที่สำคัญสำหรับวิธีคิดเกี่ยวกับการตรวจสอบความถูกต้องที่แตกต่างออกไป

นิยามของ "Status Validation"

การตรวจสอบความถูกต้องตามสถานะ (Status-Based Validation) คือรูปแบบที่การตอบกลับการตรวจสอบความถูกต้องจะถูกส่งไปยังผู้ใช้เป็นหลักเพื่อตอบสนองต่อความพยายามในการส่งฟอร์ม แทนที่จะตรวจสอบทุกครั้งที่กดแป้นพิมพ์ (`onChange`) หรือเมื่อผู้ใช้ออกจากฟิลด์ (`onBlur`) ตรรกะการตรวจสอบหลักจะทำงานเมื่อผู้ใช้ส่งฟอร์ม ผลลัพธ์ของการส่งนี้—ซึ่งก็คือ *สถานะ* ของมัน (เช่น สำเร็จ, ข้อผิดพลาดในการตรวจสอบ, ข้อผิดพลาดของเซิร์ฟเวอร์)—จะถูกนำมาใช้อัปเดต UI

แนวทางนี้สอดคล้องกับ React Server Actions อย่างสมบูรณ์แบบ server action จะกลายเป็นแหล่งข้อมูลความจริงเพียงแห่งเดียวสำหรับการตรวจสอบความถูกต้อง มันจะรับข้อมูลฟอร์ม, ตรวจสอบกับกฎธุรกิจของคุณ (เช่น "อีเมลนี้ถูกใช้ไปแล้วหรือยัง?") และส่งคืนอ็อบเจกต์สถานะที่มีโครงสร้างซึ่งบ่งบอกถึงผลลัพธ์

บทบาทของคู่หู: `experimental_useFormState`

`useFormStatus` บอกเราว่า *อะไร* กำลังเกิดขึ้น (pending) แต่มันไม่ได้บอกเราถึง *ผลลัพธ์* ของสิ่งที่เกิดขึ้น สำหรับสิ่งนั้น เราต้องการ hook ที่เป็นพี่น้องกัน: `experimental_useFormState`

`useFormState` เป็น hook ที่ออกแบบมาเพื่ออัปเดต state ตามผลลัพธ์ของ form action มันรับฟังก์ชัน action และ state เริ่มต้นเป็นอาร์กิวเมนต์ และส่งคืน state ใหม่และฟังก์ชัน action ที่ถูกครอบ (wrapped) เพื่อส่งต่อไปยังฟอร์มของคุณ

const [state, formAction] = useFormState(myAction, initialState);

• `state`: นี่จะเก็บค่าที่ส่งคืนจากการทำงานครั้งล่าสุดของ `myAction` นี่คือที่ที่เราจะได้รับข้อความแสดงข้อผิดพลาด
• `formAction`: นี่คือเวอร์ชันใหม่ของ action ของคุณที่คุณควรส่งต่อไปยัง prop `action` ของ `
  ` เมื่อสิ่งนี้ถูกเรียก มันจะทริกเกอร์ action เดิมและอัปเดต `state`

ขั้นตอนการทำงานร่วมกัน: จากการคลิกสู่การตอบกลับ

นี่คือวิธีการทำงานร่วมกันของ `useFormState` และ `useFormStatus` เพื่อสร้างวงจรการตรวจสอบความถูกต้องที่สมบูรณ์:

1. การเรนเดอร์เริ่มต้น: ฟอร์มจะเรนเดอร์ด้วย state เริ่มต้นที่ได้จาก `useFormState` ยังไม่มีข้อผิดพลาดแสดง
2. ผู้ใช้ส่งข้อมูล: ผู้ใช้คลิกปุ่ม submit
3. สถานะ Pending: hook `useFormStatus` ในปุ่ม submit จะรายงาน `pending: true` ทันที ปุ่มจะถูกปิดใช้งานและแสดงข้อความกำลังโหลด
4. การทำงานของ Action: server action (ที่ถูกครอบโดย `useFormState`) จะทำงานพร้อมกับข้อมูลฟอร์ม และทำการตรวจสอบความถูกต้อง
5. Action ส่งคืนค่า: action ไม่ผ่านการตรวจสอบและส่งคืนอ็อบเจกต์ state ตัวอย่างเช่น:
   `{ message: "การตรวจสอบล้มเหลว", errors: { email: "อีเมลนี้ถูกใช้ไปแล้ว" } }`
6. การอัปเดต State: `useFormState` ได้รับค่าที่ส่งคืนนี้และอัปเดตตัวแปร `state` ของมัน สิ่งนี้จะทริกเกอร์การ re-render ของคอมโพเนนต์ฟอร์ม
7. การตอบกลับของ UI: ฟอร์มจะ re-render สถานะ `pending` จาก `useFormStatus` จะกลายเป็น `false` ตอนนี้คอมโพเนนต์สามารถอ่าน `state.errors.email` และแสดงข้อความแสดงข้อผิดพลาดข้างๆ ช่องกรอกอีเมลได้แล้ว

ขั้นตอนทั้งหมดนี้ให้การตอบกลับที่ชัดเจนและเชื่อถือได้จากเซิร์ฟเวอร์แก่ผู้ใช้ โดยขับเคลื่อนทั้งหมดจากสถานะและผลลัพธ์ของการส่งข้อมูล

คลาสเรียนภาคปฏิบัติ: การสร้างฟอร์มลงทะเบียนหลายฟิลด์

มาทำให้แนวคิดเหล่านี้เป็นรูปธรรมด้วยการสร้างฟอร์มลงทะเบียนที่สมบูรณ์แบบสไตล์โปรดักชัน เราจะใช้ server action สำหรับการตรวจสอบความถูกต้องและใช้ทั้ง `useFormState` และ `useFormStatus` เพื่อสร้างประสบการณ์ผู้ใช้ที่ยอดเยี่ยม

ขั้นตอนที่ 1: การกำหนด Server Action พร้อมการตรวจสอบความถูกต้อง

ขั้นแรก เราต้องการ server action ของเรา สำหรับการตรวจสอบที่แข็งแกร่ง เราจะใช้ไลบรารียอดนิยม Zod action นี้จะอยู่ในไฟล์แยกต่างหาก โดยมีเครื่องหมาย `'use server';` directive หากคุณใช้เฟรมเวิร์กอย่าง Next.js

ไฟล์: actions/authActions.js

'use server'; import { z } from 'zod'; // กำหนด validation schema const registerSchema = z.object({ username: z.string().min(3, 'ชื่อผู้ใช้ต้องมีความยาวอย่างน้อย 3 ตัวอักษร'), email: z.string().email('กรุณากรอกที่อยู่อีเมลที่ถูกต้อง'), password: z.string().min(8, 'รหัสผ่านต้องมีความยาวอย่างน้อย 8 ตัวอักษร'), }); // กำหนด state เริ่มต้นสำหรับฟอร์มของเรา export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. ตรวจสอบข้อมูลฟอร์ม const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. หากการตรวจสอบล้มเหลว ให้ส่งคืนข้อผิดพลาด if (!validatedFields.success) { return { message: 'การตรวจสอบล้มเหลว กรุณาตรวจสอบข้อมูลในฟิลด์', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (จำลอง) ตรวจสอบว่ามีผู้ใช้อยู่ในฐานข้อมูลแล้วหรือไม่ // ในแอปจริง คุณจะคิวรีฐานข้อมูลของคุณที่นี่ if (validatedFields.data.email === 'user@example.com') { return { message: 'การลงทะเบียนล้มเหลว', errors: { email: ['อีเมลนี้ได้ลงทะเบียนไว้แล้ว'] }, }; } // 4. (จำลอง) สร้างผู้ใช้ console.log('กำลังสร้างผู้ใช้:', validatedFields.data); // 5. ส่งคืนสถานะสำเร็จ // ในแอปจริง คุณอาจจะ redirect ที่นี่โดยใช้ `redirect()` จาก 'next/navigation' return { message: 'ลงทะเบียนผู้ใช้สำเร็จ!', errors: {}, }; }

server action นี้เป็นสมองของฟอร์มของเรา มันสมบูรณ์ในตัวเอง, ปลอดภัย และมีโครงสร้างข้อมูลที่ชัดเจนสำหรับทั้งสถานะสำเร็จและสถานะข้อผิดพลาด

ขั้นตอนที่ 2: การสร้างคอมโพเนนต์ที่นำกลับมาใช้ใหม่ได้และรับรู้สถานะ

เพื่อให้คอมโพเนนต์ฟอร์มหลักของเราสะอาด เราจะสร้างคอมโพเนนต์เฉพาะสำหรับ input และปุ่ม submit ของเรา

ไฟล์: components/SubmitButton.js

'use client'; import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton({ label }) { const { pending } = useFormStatus(); return ( {pending ? 'กำลังดำเนินการ...' : label} ); }

สังเกตการใช้ `aria-disabled={pending}` นี่เป็นแนวปฏิบัติที่สำคัญด้านการเข้าถึง (accessibility) เพื่อให้แน่ใจว่าโปรแกรมอ่านหน้าจอจะประกาศสถานะปิดใช้งานได้อย่างถูกต้อง

ขั้นตอนที่ 3: การประกอบฟอร์มหลักด้วย `useFormState`

ตอนนี้ เรามารวมทุกอย่างเข้าด้วยกันในคอมโพเนนต์ฟอร์มหลักของเรา เราจะใช้ `useFormState` เพื่อเชื่อมต่อ UI ของเรากับ action `registerUser`

ไฟล์: components/RegistrationForm.js

'use client'; import { experimental_useFormState as useFormState } from 'react-dom'; import { registerUser, initialState } from '../actions/authActions'; import { SubmitButton } from './SubmitButton'; export function RegistrationForm() { const [state, formAction] = useFormState(registerUser, initialState); return (

ลงทะเบียน

{state?.message && !state.errors &&

{state.message}

} {state?.message && state.errors &&

{state.message}

}

ชื่อผู้ใช้ {state?.errors?.username && (

{state.errors.username[0]}

)}

อีเมล {state?.errors?.email && (

{state.errors.email[0]}

)}

รหัสผ่าน {state?.errors?.password && (

{state.errors.password[0]}

)}

); }

ตอนนี้คอมโพเนนต์นี้เป็นแบบ declarative และสะอาด มันไม่ได้จัดการ state ใดๆ ด้วยตัวเอง นอกจากอ็อบเจกต์ `state` ที่ได้จาก `useFormState` หน้าที่เดียวของมันคือการเรนเดอร์ UI ตาม state นั้น ตรรกะสำหรับการปิดใช้งานปุ่มถูกห่อหุ้มไว้ใน `SubmitButton` และตรรกะการตรวจสอบทั้งหมดอยู่ใน `authActions.js` การแยกความรับผิดชอบ (separation of concerns) นี้เป็นชัยชนะครั้งใหญ่สำหรับการบำรุงรักษา

เทคนิคขั้นสูงและแนวทางปฏิบัติที่ดีที่สุดระดับมืออาชีพ

แม้ว่ารูปแบบพื้นฐานจะทรงพลัง แต่แอปพลิเคชันในโลกแห่งความเป็นจริงมักต้องการความละเอียดอ่อนมากกว่านี้ มาสำรวจเทคนิคขั้นสูงบางอย่างกัน

แนวทางแบบผสมผสาน: การรวมการตรวจสอบแบบทันทีและหลังการส่ง

การตรวจสอบตามสถานะเป็นเลิศสำหรับการตรวจสอบฝั่งเซิร์ฟเวอร์ แต่การรอการเดินทางของข้อมูลผ่านเครือข่ายเพื่อบอกผู้ใช้ว่าอีเมลของพวกเขาไม่ถูกต้องอาจจะช้าเกินไป แนวทางแบบผสมผสานมักจะเป็นวิธีที่ดีที่สุด:

• ใช้การตรวจสอบของ HTML5: อย่าลืมพื้นฐาน! แอตทริบิวต์อย่าง `required`, `type="email"`, `minLength` และ `pattern` ให้การตอบกลับแบบทันทีและเป็นแบบเนทีฟของเบราว์เซอร์โดยไม่มีค่าใช้จ่าย
• การตรวจสอบฝั่งไคลเอ็นต์แบบเบา: สำหรับการตรวจสอบด้านการแสดงผลหรือการจัดรูปแบบล้วนๆ (เช่น ตัวบ่งชี้ความแข็งแกร่งของรหัสผ่าน) คุณยังสามารถใช้ `useState` และ `onChange` handlers ในปริมาณน้อยที่สุดได้
• อำนาจอยู่ที่ฝั่งเซิร์ฟเวอร์: สงวน server action ไว้สำหรับการตรวจสอบที่สำคัญที่สุดและเกี่ยวกับตรรกะทางธุรกิจที่ไม่สามารถทำได้บนไคลเอ็นต์ (เช่น การตรวจสอบชื่อผู้ใช้ที่ไม่ซ้ำกัน, การตรวจสอบกับข้อมูลในฐานข้อมูล)

วิธีนี้ให้คุณได้สิ่งที่ดีที่สุดจากทั้งสองโลก: การตอบกลับทันทีสำหรับข้อผิดพลาดง่ายๆ และการตรวจสอบที่เชื่อถือได้สำหรับกฎที่ซับซ้อน

การเข้าถึง (A11y): การสร้างฟอร์มสำหรับทุกคน

การเข้าถึงเป็นสิ่งที่ต่อรองไม่ได้ เมื่อใช้การตรวจสอบตามสถานะ ควรคำนึงถึงประเด็นเหล่านี้:

• ประกาศข้อผิดพลาด: ในตัวอย่างของเรา เราใช้ `aria-live="polite"` บนคอนเทนเนอร์ข้อความแสดงข้อผิดพลาด สิ่งนี้จะบอกให้โปรแกรมอ่านหน้าจอประกาศข้อความแสดงข้อผิดพลาดทันทีที่มันปรากฏขึ้น โดยไม่ขัดจังหวะการทำงานปัจจุบันของผู้ใช้
• เชื่อมโยงข้อผิดพลาดกับ Inputs: สำหรับการเชื่อมต่อที่แข็งแกร่งยิ่งขึ้น ให้ใช้แอตทริบิวต์ `aria-describedby` input สามารถชี้ไปที่ ID ของคอนเทนเนอร์ข้อความแสดงข้อผิดพลาดของมัน เพื่อสร้างการเชื่อมโยงทางโปรแกรม
• การจัดการ Focus: หลังจากส่งข้อมูลแล้วมีข้อผิดพลาด ควรพิจารณาการย้าย focus ไปยังฟิลด์ที่ไม่ถูกต้องฟิลด์แรกโดยอัตโนมัติ สิ่งนี้ช่วยให้ผู้ใช้ไม่ต้องค้นหาว่าเกิดข้อผิดพลาดที่ใด

Optimistic UI ด้วยคุณสมบัติ `data` ของ `useFormStatus`

ลองนึกภาพแอปโซเชียลมีเดียที่ผู้ใช้โพสต์ความคิดเห็น แทนที่จะแสดง spinner เป็นเวลาหนึ่งวินาที คุณสามารถทำให้แอปรู้สึกเหมือนทำงานได้ทันที คุณสมบัติ `data` จาก `useFormStatus` เหมาะสำหรับสิ่งนี้

เมื่อฟอร์มถูกส่ง `pending` จะกลายเป็น true และ `data` จะถูกเติมด้วย `FormData` ของการส่งนั้น คุณสามารถเรนเดอร์ความคิดเห็นใหม่ในสถานะภาพชั่วคราว 'pending' ได้ทันทีโดยใช้ `data` นี้ หาก server action สำเร็จ คุณก็แทนที่ความคิดเห็น pending ด้วยข้อมูลสุดท้ายจากเซิร์ฟเวอร์ หากล้มเหลว คุณสามารถลบความคิดเห็น pending และแสดงข้อผิดพลาดได้ สิ่งนี้ทำให้แอปพลิเคชันรู้สึกตอบสนองได้อย่างน่าทึ่ง

การรับมือกับสถานะ "Experimental"

เป็นสิ่งสำคัญที่ต้องกล่าวถึงคำนำหน้า "experimental" ใน `experimental_useFormStatus` และ `experimental_useFormState`

"Experimental" หมายถึงอะไรจริงๆ

เมื่อ React ติดป้ายกำกับ API ว่าเป็น experimental มันหมายความว่า:

• API อาจมีการเปลี่ยนแปลง: ชื่อ, อาร์กิวเมนต์ หรือค่าที่ส่งคืนอาจถูกเปลี่ยนแปลงใน React เวอร์ชันอนาคตโดยไม่เป็นไปตามมาตรฐาน semantic versioning (SemVer) สำหรับการเปลี่ยนแปลงที่ส่งผลกระทบ (breaking changes)
• อาจมีข้อบกพร่อง (bugs): เนื่องจากเป็นฟีเจอร์ใหม่ อาจมีกรณีพิเศษ (edge cases) ที่ยังไม่เป็นที่เข้าใจหรือแก้ไขได้อย่างสมบูรณ์
• เอกสารอาจยังมีน้อย: แม้ว่าแนวคิดหลักจะได้รับการจัดทำเป็นเอกสารแล้ว แต่คำแนะนำโดยละเอียดเกี่ยวกับรูปแบบขั้นสูงอาจยังอยู่ระหว่างการพัฒนา

เมื่อใดควรนำมาใช้และเมื่อใดควรรอ

ดังนั้น คุณควรใช้มันในโปรเจกต์ของคุณหรือไม่? คำตอบขึ้นอยู่กับบริบทของคุณ:

• เหมาะสำหรับ: โปรเจกต์ส่วนตัว, เครื่องมือภายใน, สตาร์ทอัพ หรือทีมที่พร้อมรับมือกับการเปลี่ยนแปลง API ที่อาจเกิดขึ้น การใช้งานภายในเฟรมเวิร์กอย่าง Next.js (ซึ่งได้รวมฟีเจอร์เหล่านี้เข้ากับ App Router แล้ว) โดยทั่วไปจะเป็นทางเลือกที่ปลอดภัยกว่า เนื่องจากเฟรมเวิร์กสามารถช่วยจัดการกับการเปลี่ยนแปลงบางส่วนได้
• ใช้ด้วยความระมัดระวังสำหรับ: แอปพลิเคชันระดับองค์กรขนาดใหญ่, ระบบที่มีความสำคัญสูง หรือโปรเจกต์ที่มีสัญญาการบำรุงรักษาระยะยาวซึ่งความเสถียรของ API เป็นสิ่งสำคัญยิ่ง ในกรณีเหล่านี้ อาจเป็นการรอบคอบที่จะรอจนกว่า hook เหล่านี้จะได้รับการเลื่อนขั้นเป็น API ที่เสถียร

คอยติดตามบล็อกและเอกสารอย่างเป็นทางการของ React เสมอ สำหรับประกาศเกี่ยวกับการทำให้ hook เหล่านี้มีความเสถียร

บทสรุป: อนาคตของฟอร์มใน React

การมาถึงของ `experimental_useFormStatus` และ API ที่เกี่ยวข้องนั้นเป็นมากกว่าแค่เครื่องมือใหม่ มันแสดงถึงการเปลี่ยนแปลงทางปรัชญาในวิธีที่เราสร้างประสบการณ์แบบโต้ตอบด้วย React ด้วยการยอมรับรากฐานของแพลตฟอร์มเว็บและการวางตำแหน่งตรรกะที่มีสถานะไว้บนเซิร์ฟเวอร์ เราสามารถสร้างแอปพลิเคชันที่ง่ายขึ้น, ทนทานมากขึ้น และมักจะมีประสิทธิภาพสูงขึ้น

เราได้เห็นแล้วว่า `useFormStatus` มอบวิธีที่สะอาดและแยกส่วนเพื่อให้คอมโพเนนต์ตอบสนองต่อวงจรชีวิตของการส่งฟอร์มได้อย่างไร มันกำจัด prop drilling สำหรับสถานะ pending และเปิดใช้งานคอมโพเนนต์ UI ที่สง่างามและสมบูรณ์ในตัวเอง เช่น `SubmitButton` อัจฉริยะ เมื่อใช้ร่วมกับ `useFormState` มันจะปลดล็อกรูปแบบที่ทรงพลังของการตรวจสอบตามสถานะ ซึ่งเซิร์ฟเวอร์เป็นผู้มีอำนาจสูงสุด และความรับผิดชอบหลักของไคลเอ็นต์คือการเรนเดอร์สถานะที่ส่งคืนโดย server action

แม้ว่าป้ายกำกับ "experimental" จะต้องใช้ความระมัดระวังในระดับหนึ่ง แต่ทิศทางก็ชัดเจน อนาคตของฟอร์มใน React คือการปรับปรุงแบบก้าวหน้า (progressive enhancement), การจัดการสถานะที่ง่ายขึ้น และการผสานรวมที่ทรงพลังและราบรื่นระหว่างตรรกะของไคลเอ็นต์และเซิร์ฟเวอร์ การเรียนรู้ hook ใหม่เหล่านี้ในวันนี้ ไม่ใช่แค่การเรียนรู้ API ใหม่ แต่คุณกำลังเตรียมพร้อมสำหรับยุคถัดไปของการพัฒนาเว็บแอปพลิเคชันด้วย React